Speed of information delivery is a valuable dimension to the financial instrument trading and brokerage industry. The ability of a trader to obtain analytical information (e.g., pricing, trade volume, trends, etc.) about financial instruments such as stocks, bonds and particularly options as quickly as possible cannot be overstated; reductions in information delivery delay on the order of fractions of a second can provide important value to traders. However, conventional techniques in the art which rely on software executed on a general purpose processor (GPP) to compute analytical information for financial instruments generally suffer latency issues due to the computation intensive nature of many financial instrument analytics models.
Options pricing is a function that particularly suffers from computational latency in a conventional GPP-based platform. An “option” is a derivative financial instrument that is related to an underlying financial instrument. An option is a contract that allows the option holder to trade in shares of the underlying financial instrument at a specific price at some time in the future. This future time is related to the option's lifetime (also referred to as the option's “time to maturity”), which is the amount of time after which the option to buy/sell cannot be exercised. The specific time in the future that the option-holder can exercise his/her choice depends on the type of the option; e.g., an American option can be exercised at any time during the option's lifetime while a European option can only be exercised at the end of the option's lifetime and yet other classes of options can be exercised only at certain predetermined times during their lifetime.
In the parlance of the financial market, an option to buy shares is referred to as a “call option” (or “call” for short), and an option to sell shares is referred to as a “put option” (or “put” for short). The inventors herein note that the teachings of the present invention are equally applicable to both call options and put options.
Within a financial market data stream, an offer to buy or sell an option is defined by the following characteristics: the identity of the financial instrument underlying the option (e.g., IBM stock), the number of shares of the underlying financial instrument that are covered by the option, the purchase price for the option (P), the lifetime for the option (T), the current price of the underlying financial instrument (S), and the fixed price (K) at which the option-holder has the choice to buy or sell the shares of the underlying financial instrument in the future (which is also known as the “strike price”). An option may additionally include a dividend yield (δ). Another parameter to be included in the trading of options, not directly related to the option but to the market, is the risk-free interest rate (r) at which the potential option-holder can borrow or lend money. The modifier risk-free is used to signify that this is the rate of return one could expect on an investment that has zero risk involved with it. Further options characteristics that affect option pricing include whether the option is a call or put and whether the option is an American or European option, as explained above.
Based on knowledge of the values for these option characteristics and the risk-free interest rate, a trader may then assess whether the purchase price P for the option represents a good deal for the trader. While what constitutes a “good deal” will almost assuredly vary for different traders, it is expected that most traders will have an interest in buying or selling an option if the price P for the option is deemed favorable in view of the other option characteristics. Among the challenges in making this assessment as to an option's desirability is the complexity of factors that affect option price and option desirability.
One important consideration in making such an assessment of an option is an estimate of how much the price of the underlying financial instrument can fluctuate in the future. This fluctuation in the price of the underlying financial instrument is commonly referred to as the “volatility” of the financial instrument. One measure of this volatility is to observe the historical trend of the price of the financial instrument and extrapolate the volatility from the historical trend. Another measure of the volatility can be obtained by approximating (within some degree of tolerance) the purchase price for the option (P) with a theoretical fair market option price (Pth) that depends on the volatility. The volatility so obtained is termed the “implied volatility” since it is representative of the volatility of the underlying financial instrument implied by the option. Such a theoretical fair market option price (Pth) can be calculated using an option pricing model. Various option pricing models are known in the art or used in a proprietary manner for computing theoretical option prices. Prominent among these models are the Black-Scholes option pricing model and the Cox, Ross, and Rubinstein (CRR) option pricing model, both of which are well-known in the art.
As indicated above, the downside of using some of these option pricing models to evaluate whether a buy/sell offer for an option represents a desirable transaction is that these option pricing models are very computation intensive. Because of their computation intensive nature, a delay is introduced between the time that the data regarding the option reaches a trader and the time when the trader has access to the pricing information computed from the option data (e.g., the option's implied volatility and/or the option's theoretical fair market price). This delay may be costly to the trader in that another party may have already bought the offered option while the trader was awaiting the results of the option pricing model. For example, consider the following exemplary scenario. Suppose there is an outstanding “bid” on an option for stock X that is a firm quote to sell an option to buy 100 shares of Stock X at an option price (P) of $10.00 per share, and wherein the current market price (S) for Stock X is $25 per share, and wherein the option further has values defined for K, T, and δ, and wherein r is known. Also suppose there are two traders, A and B, each wanting to buy a call option on 100 shares of stock X, but before doing so would like to know whether the option price P of $10.00 per share represents a good deal given the other option characteristics (S, K, T, and δ) and the risk-free interest rate (r). To aid this evaluation process, Trader A and Trader B both have their own implementations of an option pricing model; and they each would typically apply the values of these option characteristics to their respective implementations of an option pricing model to obtain information that is indicative of whether the call option offer represents a desirable transaction. For the purposes of this example, it will be presumed that this offer to sell the call option does in fact represent a good deal to both traders. The trader whose implementation of an option pricing model operates the fastest will have a decided market and investment advantage as he will be able to make an informed investment decision to purchase the call option before the other trader since the “winning” trader will be informed of the option's desirability while the “losing” trader is still awaiting the output from his/her respective implementation of the option pricing model. Accordingly, the “losing” trader will miss out on the desirable option because the “winning” trader will have taken that option offer off the market before the “losing” trader realized that he/she wanted to buy it. Thus, it can be seen that the speed of a trader's option pricing engine inevitably translates into a trading advantage, which even in a single large volume opportunity can amount to significant sums of money. Over time this market advantage can even lead to the success or failure of a trader to attract and keep customers and stay in business.
The ability of a computational engine that implements an option pricing model to quickly produce its output is even more significant when “black box” trading is taken into consideration. With such black box trading, the trader does not eyeball offers to buy/sell financial instruments as they tick across a trading screen to decide whether or not he/she will buy/sell a financial instrument. Instead, the trader defines the conditions under which he/she will buy/sell various financial instruments via a computer implemented algorithm. This algorithm then traverses the offers to buy/sell various financial instruments within a market data feed to identify which offers meet the specified conditions. Upon finding a “hit” on an offer within the feed, the algorithm operates to automatically execute a specified trade on the offer (without further trader intervention). Thus, returning to the above example, such an algorithm may have a specified condition to the effect of “buy a call option on X shares of ABC stock if the implied volatility for the call option is less than or equal to Z”. Another exemplary algorithmic condition could be “buy a call option on Y shares of ABC stock if the computed theoretical fair market price for that option is greater than the actual price for the option by at least Z cents”. Thus, before the algorithm can make a decision as to whether a given call option offer will be purchased, the implied volatility and/or theoretical fair market price for the option offer will need to be computed via some form of an option pricing model. As explained above, with such black box trading, the computation latency for computing the implied volatility and/or theoretical fair market price is highly important as delays on the order of fractions of a second will be critical in determining which trader is able to strike first to buy or sell options at a desirable price. Given that the inventors envision that black box trading will continue to grow in prominence in future years (for example, it is estimated that currently greater than 50% of trades are performed automatically via computer-generated “black box” transactions), it is believed that high performance computation engines for option pricing will become ever more important to the financial instrument trading industry.
Use of the CRR option pricing model for the analytics discussed above is especially computation intensive, as it is both an iterative model and a binomial model. Using the CRR option pricing model, an option's theoretical fair market price (Pth) can be computed as a function of the following inputs: P, S, K, T, δ, r, a volatility value σ, and n, wherein n represents a number of discrete time steps within the option's lifetime that the underlying financial instrument's price may fluctuate. The parameter n is specified by the user of the CRR option pricing algorithm. By iteratively updating the volatility value σ until the theoretical fair market price Pth for that option approaches the option's actual market price (P), an option's “implied volatility” (σ*) can be computed. The “implied volatility”, which represents the volatility of the underlying financial instrument at which the option's theoretical fair market price (Pth) is within some specified tolerance ε of the option's actual purchase price (P), is an important characteristic of an option that is used by traders to decide whether a given option should be bought or not. However, because of the iterative nature of the implied volatility computation and the binomial nature of the theoretical fair market price computation, the calculation of implied volatility using the CRR option pricing model is highly computation intensive, as noted above. Conventional implementations of the CRR option pricing model to compute implied volatility in software on GPPs are believed by the inventors to be unsatisfactory because of the processing delays experienced while computing the implied volatility.
Based on the foregoing, the inventors herein believe that a need in the art exists for accelerating the speed by which option pricing models can be used to evaluate option prices.
As further background, the inventors note that, in an attempt to promptly deliver financial information to interested parties such as traders, a variety of market data platforms have been developed for the purpose of ostensible “real time” delivery of streaming bid, offer, and trade information for financial instruments to traders. FIG. 12 illustrates an exemplary platform that is currently known in the art and used by traders to support their trading activities, including options trading. As shown in FIG. 12, the market data platform 1200 comprises a plurality of functional units 1202 that are configured to carry out data processing operations such as the ones depicted in units 1202 (including options pricing), whereby traders at workstations 1204 have access to financial data of interest and whereby trade information can be sent to various exchanges or other outside systems via output path 1212. The purpose and details of the functions performed by functional units 1202 are well-known in the art. A stream 1206 of financial data arrives at the system 1200 from an external source such as the exchanges themselves (e.g., NYSE, NASDAQ, etc.) over private data communication lines or from extranet providers such as Savvis or BT Radians. The financial data source stream 1206 comprises a series of messages that individually represent a new offer to buy or sell a financial instrument, an indication of a completed sale of a financial instrument, notifications of corrections to previously-reported sales of a financial instrument, administrative messages related to such transactions, and the like. As used herein, a “financial instrument” refers to a contract representing equity ownership, debt or credit, typically in relation to a corporate of governmental entity, wherein the contract is saleable. Examples of “financial instruments” include stocks, bonds, options, commodities, currency traded on currency markets, etc. but would not include cash or checks in the sense of how those items are used outside financial trading markets (i.e., the purchase of groceries at a grocery store using cash or check would not be covered by the term “financial instrument” as used herein; similarly, the withdrawal of $100 in cash from an Automatic Teller Machine using a debit card would not be covered by the term “financial instrument” as used herein).
Functional units 1202 of the system then operate on stream 1206 or data derived therefrom to carry out a variety of financial processing tasks. As used herein, the term “financial market data” refers to the data contained in or derived from a series of messages that individually represent a new offer to buy or sell a financial instrument, an indication of a completed sale of a financial instrument, notifications of corrections to previously-reported sales of a financial instrument, administrative messages related to such transactions, and the like. The term “financial market source data” refers to a feed of financial market data received directly from a data source such as an exchange itself or a third party provider (e.g., a Savvis or BT Radians provider). The term “financial market secondary data” refers to financial market data that has been derived from financial market source data, such as data produced by a feed compression operation, a feed handling operation, an option pricing operation, etc.
Because of the massive computations required to support such a platform, current implementations known to the inventors herein typically deploy these functions across a number of individual computer systems that are networked together, to thereby achieve the appropriate processing scale for information delivery to traders with an acceptable degree of latency. This distribution process involves partitioning a given function into multiple logical units and implementing each logical unit in software on its own computer system/server. The particular partitioning scheme that is used is dependent on the particular function and the nature of the data with which that function works. The inventors believe that a number of different partitioning schemes for market data platforms have been developed over the years. For large market data platforms, the scale of deployment across multiple computer systems and servers can be physically massive, often filling entire rooms with computer systems and servers, thereby contributing to expensive and complex purchasing, maintenance, and service issues.
This partitioning approach is shown by FIG. 12 wherein each functional unit 1202 can be thought of as its own computer system or server. Buses 1208 and 1210 can be used to network different functional units 1202 together. For many functions, redundancy and scale can be provided by parallel computer systems/servers such as those shown in connection with options pricing and others. To the inventors' knowledge, these functions are deployed in software that is executed by the conventional GPPs resident on the computer systems/servers 1202. The nature of GPPs and software systems in the current state of the art known to the inventors herein imposes constraints that limit the performance of these functions. Performance is typically measured as some number of units of computational work that can be performed per unit time on a system (commonly called “throughput”), and the time required to perform each individual unit of computational work from start to finish (commonly called “latency” or delay). Also, because of the many physical machines required by system 1200, communication latencies are introduced into the data processing operations because of the processing overhead involved in transmitting messages to and from different machines.
Despite the improvements to the industry that these systems have provided, the inventors herein believe that significant further improvements can be made. In doing so, the inventors herein disclose that the underlying technology disclosed in the related and incorporated patents and patent applications identified above can be harnessed in a novel and non-obvious way to fundamentally change the system architecture in which market data platforms are deployed.
In above-referenced related U.S. Pat. No. 7,139,743, it was first disclosed that reconfigurable logic, such as Field Programmable Gate Arrays (FPGAs), can be deployed to process streaming financial information at hardware speeds. As examples, the '743 patent disclosed the use of FPGAs to perform data reduction operations on streaming financial information, with specific examples of such data reduction operations being a minimum price function, a maximum price function, and a latest price function.
Since that time, the inventors herein have greatly expanded the scope of functionality for processing streams of financial information with reconfigurable logic.
In accordance with one embodiment of the invention described herein, options pricing can be performed at hardware speeds via reconfigurable logic deployed in hardware appliances to greatly accelerate the speed by which option pricing operations can be performed, thereby providing important competitive advantages to traders. Thus, in accordance with this embodiment of the invention, it is disclosed that the options pricing functionality 1202 that is performed in software on conventional platforms can be replaced with reconfigurable logic that is configured as an options pricing engine. Such an options pricing engine can perform a number of computations related to options to aid in the evaluation of whether a given option represents a desirable transaction. For example, such an options pricing engine can be configured to compute an implied volatility for an option or a theoretical fair market price for an option. The inventors further disclose that in addition to options pricing, other functions of a conventional market data platform can be deployed in reconfigurable logic, thereby greatly consolidating the distributed nature of the conventional market data platform into fewer and much smaller appliances while still providing acceleration with respect to latency and throughput.
As used herein, the term “general-purpose processor” (or GPP) refers to a hardware device that fetches instructions and executes those instructions (for example, an Intel Xeon processor or an AMD Opteron processor). The term “reconfigurable logic” refers to any logic technology whose form and function can be significantly altered (i.e., reconfigured) in the field post-manufacture. This is to be contrasted with a GPP, whose function can change post-manufacture, but whose form is fixed at manufacture. The term “software” will refer to data processing functionality that is deployed on a GPP. The term “firmware” will refer to data processing functionality that is deployed on reconfigurable logic.
According to another aspect of the invention, the inventors herein have streamlined the manner in which an option's implied volatility and fair market price can be computed, thereby providing acceleration independently of whether such functionality is deployed in hardware or software. While it is preferred that the implied volatility and fair market price computations disclosed herein be performed via firmware pipelines deployed in reconfigurable logic, the inventors herein further note that the architectural improvements with respect to how the implied volatility and/or fair market prices can be computed can also provide acceleration when performed in hardware on custom Application Specific Integrated Circuits (ASICs), in software on other platforms such as superscalar processors, multi-core processors, graphics processor units (GPUs), physical processor units (PPUs), chip multi-processors, and GPPs, or in a hybrid system involving exploitation of hardware, including reconfigurable hardware, and software techniques executing on a variety of platforms.
With respect to computing an option's implied volatility, the inventors disclose that an iterative banded m-ary search within the option's volatility space can be performed to identify the volatility value for which the option's theoretical fair market price, computed according to an option pricing model, approximates the option's actual purchase price to within a predetermined tolerance. This identified volatility value for which the option's computed theoretical fair market price approximates the option's actual purchase price to within a predetermined tolerance can then be used as the option's implied volatility.
With this iterative banded m-ary approach, a plurality m+1 theoretical fair market prices are preferably computed in parallel for different volatility values within the volatility space for a given iteration, thereby providing acceleration with respect to the computation of the implied volatility. At least one, and preferably a plurality of conditions are tested to determine whether an additional iteration is needed to find the implied volatility. As explained hereinafter, a theoretical fair market price convergence property (ε) is preferably used as one of these conditions. Also as explained hereinafter, a volatility convergence property (εσ) is preferably used as another of these conditions.
Preferably, the option pricing model that is used to compute the option's theoretical fair market price is the CRR option pricing model. To accelerate the computation of the option's theoretical fair market price according to the CRR model, disclosed herein is a technique for parallelizing and pipelining the computation of the intermediate prices at different time steps within the CRR binomial tree, thereby providing acceleration with respect to the computation of the theoretical fair market price according to the CRR option pricing model.
In accordance with another embodiment of the invention, disclosed herein is a technique employing a lookup table to retrieve precomputed terms that are used in the computation of a European option's theoretical fair market price. Optionally, the theoretical fair market option price can then be used to drive a computation of the implied volatility as described above. Preferably, this lookup table is indexed by the European option's volatility and time to maturity. Furthermore, in an embodiment wherein the lookup table is used to compute a European option's theoretical fair market price but not its implied volatility, it is preferred that an additional lookup table of volatility values indexed by financial instruments be employed to identify a volatility value applicable to the underlying financial instrument of the subject European option. The lookup table terms retrieved from the table and indexed by the option's volatility and time to maturity can be fed to a combinatorial logic stage that is configured to accelerate the computation of the theoretical fair market price by parallelizing the computation of the constituent components of a summation formula for determining the option's theoretical fair market price.
In accordance with yet another embodiment of the invention, disclosed herein is a technique for directly computing the terms that are used in the computation of the option's theoretical fair market price. With this technique, a plurality of parallel computation modules are preferably employed to compute each term in parallel, thereby accelerating the overall computation of the option's theoretical fair market price.
Further still, to better map these computational modules onto available processing resources, a partitioning scheme can optionally be employed to distribute portions of the term computations across different processing resources.
As noted above, these parallel/pipelined architectures for computing an option's implied volatility and/or theoretical fair market price are preferably deployed in reconfigurable logic, thereby providing not only data processing at hardware speeds but also providing flexibility with respect to the parameters and models used in the computations. Preferably, a firmware pipeline is deployed on the reconfigurable logic to accelerate at least a portion of these parallel/pipelined architectures, as explained in greater detail hereinafter. However, as stated above, it should be noted that processing resources other than reconfigurable logic can be used to implement the streamlined options pricing architectures described herein.
These and other features and advantages of the present invention will be understood by those having ordinary skill in the art upon review of the description and figures hereinafter.